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(54) Method of securely loading commands In a smart card 

(57) The invention relates to a method of securely 
loading and validating commands (COM) in a smart 
card (SC). Especially in the case where application -spe- 
cific commands are loaded by an application provider 
(AP), that is off-line with respect to the card issuer (CI), 
it must be ensured that the commands are valid. The 
invention provides a method involving the protection of 
the commands (COM) by means of authentication 
codes, these codes (MAC1, MAC2) being produced 
using two different keys: one key (K1) is stored by the 
card issuer (CI), the other (K2) by a trusted third party 
(TTP). A further authentication code (MAC3), produced 
using a key from a set of keys (K3*), may be utilized to 
selectively validate commands for individual applica- 
tions (e.g. AP1, AP2). 
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Description 

BACKGROUND OF THE INVENTION 

The present invention relates to a method of load- 
ing commands in a smart card. More specifically, the 
present invention relates to a method of off-line loading 
application specific commands in a smart card. 

In modern payment systems, the use of electronic 
payment means becomes increasingly important Elec- 
tronic payment means, such as memory cards and 
smart cards, are gaining acceptance as their applica- 
tions are expanded. In many contries electronic cards 
are being used for public telephones and the like. 
Advanced cards are capable of containing electronic 
"purses", in addition to other functionalities. Such 
advanced payment means contain, in addition to a 
memory, a processor capable of running suitable pro- 
grams. 

It should be noted that in this text, the terms smart 
card or card will be used to denote electronic payment 
means having at least one integrated electronic circuit 
comprising a processor and a memory. The actual 
shape of a so-called smart card is not of importance. 

The programs running on the processor of a smart 
card determine the services offered by the card, that is, 
the functions and associated data structures (e.g. 
purse, user identification, loyalty program) of the smart 
card depend on the software present in the card. As 
time passes, the need often arises to update the pro- 
grams of the card, for example in order to add a new 
function or to improve an existing function. To this end, 
the card should be able to accept new programs which 
may replace other programs. However, it must be ascer- 
tained that the newly loaded programs are valid. 

Authentication of programs can relatively easily be 
accomplished by using a secure data exchange proto- 
col between the card issuer and the card. However, 
other parties, such as applications providers, want to be 
able to load new applications (and hence new com- 
mands) into a card without having to do this via the card 
issuer. 

SUMMARY OF THE INVENTION 

It is an object of the invention to overcome the 
above-mentioned and other disadvantages and to pro- 
vide a method which allows commands to be loaded 
and activated in a smart card in a secure manner. It is a 
further object of the present invention to provide a 
method which allows application-specific commands to 
be loaded in a smart card by an application provider 
while being able to guarantee the integrity of the com- 
mands. 

These and other objects are achieved by a method 
of securely loading commands in a smart card by a first 
party, the card being issued by a second party, the 
method according to the invention comprising the steps 
of: 



the second party producing a first authentication 
code of a command using a first key, 

- a third party producing a second authentication 
code of the command using a second key, 

5 - transferring the command with the codes to the 
card, 

- the card validating the command by reproducing 
the first and second authentication codes using the 
f irst and the second key respectively and compar- 

w ing the reproduced codes with the transferred 
codes. 

In the method of the present invention, the authen- 
ticity of the commands is thus safeguarded by having 

is two different and preferably independent parties pro- 
duce an authentication code: the second party, which 
normally is the card issuer, and a third party, which nor- 
mally is a trusted independent party, such as a central 
bank. Once both authentication codes have been pro- 

20 duced, it is virtually impossible to alter the commands 
without this being noticeable by means of the authenti- 
cation codes. The first party, the application provider, 
has proof that both the first and second parties have 
"certified" the command. Preferably the third party 

25 stores copies of the command. 

It will be understood that the method of the inven- 
tion applies to both the loading of a single command 
and the loading of a set of commands. 

The transferring to the card and the subsequent val- 

30 tdation are preferably repeated when the validation fails, 
the use of the loaded commands being blocked until the 
validation succeeds. This prevents invalid commands, 
i.e. commands affected by transmission errors or 
manipulations, to be executed by the card. 

35 Advantageously, the loaded commands are perma- 
nently disabled when the validation fails a predeter- 
mined number of times, the number preferably being 
less than ten. The disabling of the loaded commands 
may be performed by changing the key of the second 

40 party. In this way, the indefinite reloading of corrupted 
commands can be terminated. 

The commands loaded may be application-specific 
commands, i.e. commands directly influencing the 
applications of the card. Such commands are often 

45 machine language instructions which in principle allow 
manipulation of the card applications. By using the 
method of the present invention, the use of such com- 
mands is controlled whereby the integrity of the applica- 
tions is ensured. 

so The first and/or second authentication codes are 
preferably message authentication codes produced 
according to the ANSI X9.19 standard. 

Advantageously, an additional authentication code 
is produced by the second party, said additional code 

55 not involving the first or second key. This allows the first 
party a validity check without influencing the method as 
such. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 shows a smart card as may be used in the 
method of the present invention. 

Fig. 2 schematically shows the integrated circuit of s 
the smart card of Fig. 1. 

Fig. 3 schematically shows the exchange of data in 
the method of the present invention. 

Fig. 4 schematically shows data structures on a 
smart card. 10 

Fig. 5 schematically shows a flag register as used 
in the method of the present invention. 

Fig. 6 schematically shows an exemplary embodi- 
ment of the method of the present invention. 

75 

EXEMPLARY EMBODIMENTS 

The smart card or IC card 1 shown by way of exam- 
ple in Fig. 1 comprises a substrate 2, in which an inte- 
grated circuit is embedded. The integrated circuit is 20 
provided with contacts 3 for contacting a card reader or 
the like. It should be noted that the present invention 
can also be applied in the case of so-called contactless 
smart cards. 

The integrated circuit 10 shown schematically and 25 
by way of example in Fig. 2 comprises a processor 1 1 , 
a memory 12 and an input/output circuit 13. The mem- 
ory may comprise a volatile (RAM) memory part for 
temporarily storing data and a non-volatile (ROM) mem- 
ory part for permanently or semi-permanently storing 30 
data. The latter part is preferably an EEPROM type 
memory. The data stored in the non-volatile part may 
contain both programming data (instructions, programs) 
and payment data, i.e. data relating to monetary trans- 
actions. It will be understood that a separate memory 35 
(not shown) may be provided to store the instruction set 
of the processor 11. The input-output circuit 13 may 
communicate with external devices via contacts (not 
shown in Fig. 2), such as the contacts 3 shown in Fig. 1 . 
The integrated circuit 10 may be contained in the card 1 40 
of Fig. 1. 

An embodiment of the method according to the 
invention is shown schematically and by way of example 
in Fig. 3. A first party, e.g. an application provider AP, 
offers card functions to its customers. A smart card SC 45 
is issued by a second party, a card issuer CI. According 
to the invention, a trusted third party TTP is involved in 
the validation of commands, as will be explained later. 

A set of commands COM may have been produced 
by the card issuer CI or by an external source by order so 
of the applications provider AP. ft should be noted that 
the set of commands COM may comprise one or more 
commands. That is, the method as described here may 
be applied to individual commands or to a set of com- 
mands. In the following description, a single command ss 
rather than a set will be used as an example to explain 
the method of the invention. The commands may be 
application-specific commands (ASC) or general pur- 
pose commands (GPC). 



As shown in Fig. 3, the application provider AP 
offers a command (COM) to the card issuer CI for 
authentication. A first authentication code MAC1 , based 
on the command COM, is produced by the card issuer 
CI using a first key K1 . In addition to the code MAC1 the 
set of commands may optionally receive an additional 
(fourth) authentication code MAC4 which does not 
involve the use of a key, at least not the key K1 . The 
additional authentication code MAC4 serves to provide 
an additional verification of the command, independent 
of the keys used in the other authentication codes. The 
computation of the additional authentication code 
MAC4 may involve the first authentication code MAC1. 
In that case, the additional authentication code can be 
written as: 

MAC4 = F Kl (COM,MAC1), 
where F denotes a function by which the code is deter- 
mined. The authentication code MAC1, and optionally 
the additional authentication code MAC4, is transferred 
to the application provider AP, where it is temporarily 
stored. 

According to the present invention, the command 
COM is also offered to a trusted third party TTP. The 
third party produces a second authentication code 
MAC2 of the command COM, using a second key K2. 
The second authentication code MAC2 is transferred to 
the application provider AP. The third party is e.g. a cen- 
tral bank or an institution appointed by the card issuer 
and the service provider. 

The application provider AP may produce a third 
authentication code MAC3 using a third key K3\ It 
should be noted that the key K3* may comprise a set of 
keys (as denoted by the asterisk), each individual key 
corresponding with an individual card application and/or 
individual card file. The key K3*. which may thus consist 
of a set of keys K3-1 . K3-2. etc., may be used to selec- 
tively load commands into specific applications and/or 
files of the card. This will further be explained with refer- 
ence to Figs. 4 and 5. It should be noted that as the third 
key (K3) may vary between applications, the third 
authentication code (MAC3) also varies. That is, the 
third authentication code (MAC3) may constitute an 
application-specific authentication code. It should be 
noted that the third authentication code may be based 
on both the command COM and the first and second 
authentication codes, thus providing a double authenti- 
cation. In that case, the third authentication code can be 
written as: 

MAC3 = Fk3(COM, MAC1, MAC2) , 
where F denotes a function by which the code is deter- 
mined. 

The authentication codes MAC1 and MAC2, as well 
as the authentication codes MAC3 and MAC4, are pref- 
erably produced using a message authentication 
scheme involving encryption. Such a scheme is e.g. dis- 
closed in the ANSI X9.19 standard. It will be understood 
that the actual scheme (or schemes) used in producing 
the message authentication codes is not essential to the 
present invention. The additional authentication code 
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may also be produced using encryption (ag. using a 
public key), or may be produced using a so-called hash 
function. 

Both authentication codes MAC1 and MAC2, as 
well as the optional authentication codes MAC3 and s 
MAC4, may be appended to the command, or be asso- 
ciated with the command in another manner, in Fig. 3, 
the command and its associated authentication codes is 
denoted by: 

COM, MAC1 , MAC2 [ ,MAC3, MAC4] , 10 
the square brackets indicating the optional codes. The 
actual order in which the command and its associated 
codes is transferred may of course vary. 

Upon receipt of the command by the card SC, the 
card reproduces the authentication codes MAC1 and is 
MAC2 using the keys K1 and K2 which have been 
stored in the card previously. The reproduced codes 
MACV and MAC2* are compared with the received 
codes MAC1 and MAC2. If the reproduced and received 
codes are identical, the validation of the commands has 20 
succeeded and the commands may be activated. This 
activation may be done by setting (or resetting) a certain 
flag, rf the validation fails, i.e. if the corresponding 
received and reproduced codes are not identical, a 
request for retransmission of the commands may be 25 
issued. A retransmission counter keeps track of the 
number of retransmissions and inhibits retransmission if 
a predetermined number (e.g. 5) is exceeded. 

The card is thus preferably arranged in such a way 
that the commands loaded into the card cannot be used 30 
until they are activated. That is, the loaded commands 
are blocked until they are released as a result of a posi- 
tive validation. This prevents invalid commands to be 
executed by the card. 

Fig. 4 schematically shows data structures on a 35 
smart card, such as the card 1 of Fig. 1 , according to a 
preferred embodiment of the present invention. The 
data structures are in practice stored in a memory, such 
as the memory 12 of Fig. 2. 

A so-called master f ile MF contains, i.a. , references 40 
to other files. Other files are associated with individual 
applications. In Fig. 4, several so-called application files 
(AP1, AP2, AP3) are shown. Each application (or appli- 
cation file) AP1, AP2, ... t may comprise one or more 
subfiles. e.g. program files and data files. 45 

As shown in Fig. 4, each application contains a cor- 
responding key: application 1 contains key K3-1, appli- 
cation 2 contains key K3-2. etc. These keys K3-i 
correspond with the keys K3-i of the set of keys K3* of 
Fig. 3 (i denoting the 1 th application). As set out above, so 
the card is able to regenerate authentication codes (e.g. 
MAC1, MAC2) of a command, using one or more keys 
(e.g. K1, K2), and to compare the regenerated codes 
(e.g. MAC1 , MAC2) with the received codes in order to 
verify the received command. That is, if the received ss 
and the regenerated authentication codes (e.g. MAC2 
and MAC2 1 ) do not match, the corresponding command 
is not loaded into the card, or at least is barred from exe- 
cution. Similarly, the keys of the set K3* may be used to 



selectively load commands into individual applications, 
the target application (e.g. AP2) being indicated by the 
corresponding key (ag. K3-2). In case a certain com- 
mand must be loaded into more than one application, 
the key K3 may contain a wildcard. 

As is illustrated in Fig. 4, the master file MF con- 
tains a flag register FR. In fig. 5, the flag register FR is 
rendered in more detail. The flag register FR comprises 
a plurality of flags F-1 , F-2, ... of e.g. one bit each. Each 
flag corresponds with a command of the processor (1 1 
in Fig. 2) of the card. The processor and/or its software 
is arranged in such a way that the execution of a com- 
mand is inhibited if its corresponding flag is set. The 
UPDATE command, which updates a memory location, 
may e.g. only be executed if F-3 is set. Thus an addi- 
tional protection is provided against the unauthorized or 
inadvertent execution of (application specific) com- 
mands. 

The flag register can be controlled by a suitable 
command, ag. SET_FLAG-i, where i is the flag number. 
If the commands concerned are application-specific 
commands, all flags are preferably initially set, thus pre- 
venting the execution of application-specific commands. 
A flag may be reset by a command-validating command 
(e.g. VALIDATE), i.e. if the authenticity of the command 
has been verified and the execution of the command is 
allowed. It will be understood that the flag register FR 
may be located in other files that the master file MF, and 
that more than one flag register may be contained in a 
card. 

The flow diagram of Fig. 6 schematically shows an 
embodiment of the method of the present invention. In 
step 100, the procedure is initialised. This may involve 
producing one or more commands and offering the 
command to the application provider AP, who may in 
turn transfer the command to the card issuer CI and the 
third party TTP. 

In step 101, the card issuer CI produces a first 
authentication code MAC1 of the command (COM in 
Fig. 3) using the first key K1. The code MAC1 is trans- 
ferred to the application provider AP. The command may 
have been transferred to the card issuer CI in step 101 
or previously, e.g. in step 100. 

Similarly, in step 102, the third party TTP produces 
a second authentication code MAC2 of the command 
(COM in Fig. 3) using the second key K2. The code 
MAC2 is transferred to the application provider AP. The 
command may have been transferred to the third party 
in step 102 or previously, e.g. in step 100. 

In step 103, the application provider AP transfers 
the command COM with the associated authentication 
codes MAC1 and MAC2 to the smart card SC (cf. Fig. 
3). In step 104, the smart card SC essentially repro- 
duces the codes MAC1 and MAC2 by producing 
authentication codes MACV and MAC2' of the com- 
mand COM, using the keys K1 and K2 respectively. In 
step 105, the reproduced code MAC1 ' is compared with 
the received code MAC1 . If the codes are equal, control 
is transferred to step 106. otherwise the procedure is 
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exited. 

If the procedure is exited, the command COM 
received by the card is effectively inhibited, either by 
erasing the command or by setting a flag in the flag reg- 
ister. A retransmission of the command COM and its 5 
associated authentication codes may be requested. 
Preferably the number of retransmissions is monitored 
and the retransmitting may be terminated if the number 
of attempts exceeds a predetermined number, e.g. 
three or five. to 

In step 106, the reproduced code MAC2* is com- 
pared with the received code MAC2. If the codes are 
equal, control is transferred to step 107, otherwise the 
procedure is exited. 

in step 107, the smart card SO enables the com- is 
mand COM, e.g. by resetting the corresponding flag in 
the flag register FR (cf. Fig. 5). The command COM may 
now be invoked and executed. In step 108, the proce- 
dure is terminated. 

In the diagram of Fig. 6, only the essential steps of 20 
a preferred embodiment have been shown. Additional 
steps, such as the determining and evaluating of the 
third and fourth authentication codes MAC3 and MAC4, 
have been omitted for the sake of clarity. It will thus be 
understood by those skilled in the art that the embodi- 25 
ments described above are given by way of example 
only and that many modifications and additions are pos- 
sible without departing from the scope of the present 
invention. 

30 

Claims 

1 . Method of securely loading commands (COM) in a 
smart card (SC) by a first party (AP), the card (SC) 
being issued by a second party (CI), the method 35 
comprising the steps of: 

• the second party (Ci) producing a first authen- 
tication code (MAC1) of a command using a 
first key (K1), 40 

- a third party (TTP) producing a second authen- 
tication code (MAC2) of the command using a 
second key (K2), 

- transferring the command (COM) with the 
codes (MAC1 . MAC2) to the card, 45 

- the card (SC) validating the command (COM) 
by reproducing the first (MAC1) and second 
(MAC2) authentication codes using the first 
(K1) and the second (K2) key respectively and 
comparing the reproduced codes (MACV, so 
MAC2 1 ) with the transferred codes (MAC1, 
MAC2). 

2. Method according to claim 1 , wherein the transfer- 
ring to the card (SC) and the subsequent validation 55 
are repeated when the validation fails, the use of 
the loaded command (COM) being blocked until the 
validation succeeds. 



3. Method according to claim 2, wherein the loaded 
command (COM) is permanently disabled if the val- 
idation fails a predetermined number (N) of times, 
the number (N) preferably being less than ten. 

4. Method according to claim 3, wherein the disabling 
is performed by the card (1) changing the key (K1) 
of the second party (CO stored in the card. 

5. Method according to any of the preceding claims, 
wherein the command (COM) is an application-spe- 
cific command (ASC). 

6. Method according to any of the preceding claims, 
wherein the first (MAC1) and/or second (MAC2) 
authentication codes are message authentication 
codes produced according to the ANSI X9.19 
standard. 

7. Method according to any of the preceding claims, 
wherein the card contains several applications (e.g. 
AP1, AP2), each application being provided with an 
individual third key (e.g. K3-2) for validating a com- 
mand provided with a third authentication code 
(MAC3), said third authentication code being pro- 
duced using the individual third key (K3-2). 

8. Method according to any of the preceding claims, 
wherein the second party (CI) produces a fourth 
authentication code (MAC4) of the command 
(COM), said fourth code (MAC4) not involving the 
first (K1) or second (K2) key. 

9. Method according to any of the preceding claims, 
wherein the card comprises a flag register (FR), 
each flag (F-1, F-2, ...) corresponding with a com- 
mand of the processor (1 1), the execution of a com- 
mand being inhibited if its flag (e.g. F-2) is set. 

10. Card (1), comprising a substrate (2) and an inte- 
grated circuit (10) having a processor (11) and a 
memory (1 2), the memory containing keys (e.g. K1 , 
K2), Characterised in that the integrated circuit (10) 
is arranged to regenerate, using at least two keys 
(e.g. K1, K2), authentication codes (MAC1, MAC2) 
of a received command (COM) and to compare 
regenerated authentication codes (MACV, MAC2') 
with received authentication codes (MAC1, MAC2). 

11. Card according to claim 10, the memory (12) com- 
prising a data structure having individual applica- 
tions (e.g. AP1, AP2), each application containing 
an individual key (e.g. K3-1, K3-2) for regenerating 
authentication codes and selectively loading com- 
mands associated with the authentication codes. 

12. Card according to claim 10 or 1 1 , the memory (12) 
comprising a flag register (FR), each flag (F-1 , F-2, 
...) corresponding with a command of the processor 
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its flag (e.g. F-2)isset 
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